In the art of computer programming, there are various tools to assist with the designing of a software program (e.g. application program). One category of such program design tools is the visual modeling type. The UML is an example visual modeling language (with formal syntax and semantics) for communicating a model or conceptionalization. The modeling language specification specifies modeling elements, notation and usage guidelines and not order of activities, specification of artifacts, repository interface, storage, run-time behavior and so forth.
In general, at the modeling level a “problem” is posed in terms of a customer's needs and requirements and may be referred to as the business problem system. The software designer develops a “solution” software product and or service that addresses the problem. The UML syntax enables software designers to express (specify and document) the subject problems and solutions in a standardized manner, while the UML semantics enable knowledge about the subject system to be captured and leveraged during the problem solving phase. See “UML in a Nutshell” by Simon Si Alhir, published by O'Reilly & Associates, September 1998. As such, the UML enables the sharing of information (including prior solution portions) and extension (without reimplementation) of core object oriented concepts (analysis and design) during the iterative problem-solving process for designing software products.
One of the problems with many visual modeling applications is that they are difficult to use. A palette often provides the possible tools that can be used to create shapes and connectors. This requires the user to constantly be going back and forth between the palette and the drawing surface. It is also difficult to provide hints as to what types of things the user should be creating (e.g., what types of connectors should go between certain shapes). The user, especially those new to UML, effectively play a guessing game as to which connections are legitimate between UML elements on the working diagram.
Existing modeling tools (i.e., ArgoUML) have some solutions for this in the form of connector handles around a shape from which new connectors can be created. The typical implementation has a set of connector handles each representing a different semantic relationship type for the user to create. The problem is that for shapes that support a lot of relationships, the border of the shape can get quite cluttered. This leads to some usability issues which ironically is what the connector handles are trying to solve. First, when the handles are invoked, this creates an “explosion” of handles around the shape which can cause the user to be inhibited by the choices available. Often the user won't understand the symbolic meaning of the handles and just know that a relationship needs to be created. The assumption is that the user has expert level domain knowledge of the relationships and what the relationships mean.
For different types of elements, the handles that are available around the shape change because different elements may support different types of relationships as a source. This means that the user interface (UI) for the handles becomes inconsistent across shapes and semantic domains. As a result the user does not gain a familiarity of the UI across all shapes and needs to learn the available handles and positions on a per shape basis.
Another issue is that typically these handles are only available for source to target relationship creation. This is assuming that the user only considers creation of relationships in this manner. If a user is thinking contextual to the target and who may consume the capabilities of this target, the user's mouse cursor is probably hovering over that shape. However, if the user now wishes to create a relationship to the target, the user must navigate his mouse/cursor to the source shape, invoke the handles and then draw the relationship. This partially defeats the purpose of the handles in that it is forcing movement of the mouse when a contributor to the relationship was literally under hand! A similar issue is if the target of the mouse cursor is on the opposite side of the source shape from the connector handle, the user is required to move the cursor across the source shape to the connector handle and drag across the source shape to the target. This feels awkward since the source shape effectively gets in the way of the gesture and forces redundant mouse/cursor movement.